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INTRODUCTION 

iti  an  attempt  to  formalize  the  deaign  proceaa  for  lart^e  digital 
ayatema  many  reaearchera  have  advocated  the  uae  of  deaign 
languagea(DL)  [ Bar72 ,Chu72 , Dul ,Mud75 ,Met ] . In  thia  theaia  we 
preaent  a tranalator  which  createa  machine  aimulatora  from  one  auch 
DL;  thia  DL  ia  uaed  to  deacribe  large  aaynchronoua  digital 
ayatema['iud,Pet] . 

The  purpoae  for  building  aimulatora  ia  threefold.  Firat,  a 
aoftware  aimulator  will  facilitate  the  teating  of  a deaien  at  the 
functiorial  level  and  will  obviate  teating  of  a breadboarded  deaign 
at  thia  level.  Second,  the  aimulator  will  permit  the  deaigner  to 
eaaily  change  the  deaign  and  try  different  approachea  without  coatly 
rewiring  and  time  expenditurea.  Third,  the  aimulator  cari  detect 


atructural  problema 

auch  aa  hangupa  in 

the 

control  atructure 

or 

non-determlniam 

of 

the  data  atructure. 

Theae 

problema  might  not 

be 

detected  in  a 

ha: 

rdwired  deaign  for 

aorae 

time  after  it 

waa 

operational  and  would  be  difficult  to  locate. 

Thia  theaia  will  deacribe  how  aimulatora  are  created  by  the 
tranalator  and  aome  of  the  problema  that  were  encountered  that  are 
unique  to  aaynchronoua  ayatema.  Thia  theaia  ia  not  intended  to  be  a 
programming  manual  or  a detailed  deacription  of  each  and  every 
routine.  It  ia  an  overview  of  the  tranalator  and  the  tranalating 
proceaa. 
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L>-t 'o  aee  how  the  different  phased  of  the  tr’aridlator  are  tied 
toirether.  Th<^n  we  will  look  at  each  phaae  indivlduallv. 

'^'inat  the  data  atruoture  ia  read  arid  a data  baae  ia  built  baaed 
oti  a oeriPa  of  di^olaratiori  atatementa . In  the  prooeaa  of  creatine 
the  data  baae,  we  check  for  errora  and  incoriaiotenciea.  If  the  data 
baae  ia  larpelv  correct,  we  will  ,eo  to  the  aecond  phaae,  in  which  we 
arialyr.e  the  ayntax  of  the  input  arid  generate  the  appropriate  code. 
The  ayntaX  ia  analyzed  uaing  a atate  diagram  and  a paraer,  which  haa 
aoTie  error  recovery  procedurea  to  patch  up  aimole  errora  ao  the 
parainsr  can  coritinue.  If  all  errora  can  be  corrected  we  theri  go  to 
the  laat  phaae,  the  actual  aimulation  of  the  deaigti.  The  aimulator 
that  ia  generated  by  the  tranalator  ia  paaaed  to  the  SAIL  compiler, 
and  then  compiled  and  executed.  With  thia  aimulator,  the  uaer  Can 
uae  SAIL 'a  debuggiriK  package  to  teat  the  deaign. 

The  atructure  of  thia  theaia  ia  aa  followa.  Chapter  2 will 
review  the  DL,  diacuaaing  aome  of  the  limitationa  impoaed  on  the 
regiater  tranafer  atatementa,  aome  of  the  problema  inherent  to  an 
aaynchronoua  digital  deaign,  and  finally  the  choice  of  SAIL  aa  our 
programming  language.  Chapter  3 will  diacuaa  the  idea  of  a data 
baae,  how  data  typea  are  declared  and  how  the  data  baae  ia 
implemented.  Chapter  U will  examine  ayntax  arialyaia  and  code 
generation.  Chapter  5 will  preaent  a deaign  examole  and  a aimulator 
created  to  teat  the  deaign.  Chapter  6 will  conclude  the  report  with 
a diacuaaion  of  the  methodology  uaed  in  building  the  tranalator  and 
different  areaa  of  future  growth  for  the  tranalator. 
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Chapter  2 


OENERAL  STRUCTURE 

A desi<cn  is  a complex  network  of  control  structure  (CS)  modules 
forming  the  CS,  which  controls  register  transfers  in  the  data 
structure.  This  network  consists  of  a hierarchy  of  sub-networks 
organized  in  a top  down  manner.  A sub-network  at  a higher  level  can 
control  several  sub-networks  at  a lower  level.  Communications 
between  sub-networks  go  from  level  to  level  but  not  laterally,  see 
Fig  2.1  . This  collection  of  sub-networks  forms  a tree  structure 
where  each  node  represents  a sub-network.  Each  node  is  called  a 
"process" . 

Each  process  is  composed  of  two  basic  statement  tynes,  the 
register  transfer  (reg-trf)  or  the  process  call  (proc-call).  A 
block  of  statements  is  illustrated  in  Fig  2.2a.  Statements  1 and  3 
are  reg-trf  statements.  Statements  2 and  are  proc-calls.  These 
statements  are  analogous  to  assignment  expressions  and  procedure 
calls  in  programming  languages.  The  order  in  which  the  statement 
types,  reg-trf  and  oroc-call,  are  to  be  executed  is  indicated 
explicitly  by  the  number(s)  in  parentheses  (order-info)  to  the  right 
of  the  statement.  If  order  information  does  not  appear  then  the 
statement  number  (order  number)  is  taken  to  be  statement  number 
zero(O).  This  can  most  easily  be  illustrated  by  a directed  graph  as 
in,  Fig  2.2b.  The  ordering  must  form  a partial  ordering  with 
statement  number  zero  (0)  as  the  top  most  node  in  the  ordering. 
Statement  zero  is  implied  to  be  the  entry  point  of  the  block,  and  as 
such,  statement  number  zero  is  nai  used  by  basic  statements  except 


2) Block2  (1) 

3) D-<-S  (1) 

4)  Block  3 (2,3) 


Pie 


A Block 


Fiff  2.?b 
Dlr»ct»1  GPdpf 
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the  control  statements  (to  be  discussed  later)  which  have  no  effect 
on  the  orderine.  This  method  of  explicitly  declarino;  the  order  of 
statement  execution  allows  the  desicner  to  declare  the  concurrency 
he  wishes  in  executini;  the  sub-network.  This  is  an  excellent  tool 
that  other  DL's  don't  have,  however,  it  is  potentiallv  daneerous 
because  unrestricted  use  raav  cause  the  control  structure  to  be 
non-determinate . 

A collection  of  these  basic  statements  is  eenerallv  called  a 
block.  There  are  three  different  types  of  blocks:  PPOC,  DPROC,  and 
WPROC.  The  PROC  represents  a collection  of  the  basic  statements 
without  any  control  structure, see  Fig  2.3a.  The  DPROC  represents  a 
branch  depending  on  its  branch  variable;  this  is  analogous  to  a 
CASE  statement.  Control  is  passed  to  one  of  the  blocks  listed  in 
the  DPROC  or  returned  immediately  to  the  block  callin'?  the  DPROC, 
Fig  2.3h.  The  WPROC  consists  of  a collection  of  basic  statements 
but  is  only  initiated  if  the  predicate,  controllimr  entry  into  the 
block,  is  true.  Upon  completion  the  block  will  be  reinitiated  only 
if  the  predicate  is  true;  this  is  analogous  to  a WHILE  statement. 
Fig  2.3c. 

We  present  an  example  using  all  three  blocks  in  Flit  2.^. 

There  is  a third  statement  type,  control  statement 
(control-stmt),  in  the  translator  which  is  not  found  in  the  DL. 
This  statement  type  was  incorporated  to  aid  in  debugging  the  design 
and  in  controlling  some  of  the  code  generated  for  the  simulator. 
This  statement  type  has  no  effect  on  the  design.  The  three 


statements  of  this  tvpe  are  CHECKPOINT,  OPEPATIONICHECK  ION,  and 


Fitr  2.3a 
P»OC 


Fl(f  2.3b 
DPPOC 


I 

WHILE  X = l_DO 

1)  A 

2) DI-^S1  (1) 

3) D2-<-S2  (1) 


Flp  2.3c 
WPROC 


Fi(f 


Exa-nple  Bloeka 


WHILE  RUN  = QN  DO 

1)  DECI 

?)  FETCH  (1) 


DECI 

DECODE  I NT  ^ 

1 DOES  INTERRUPT  ! INTERRUPT  SIGNALED 

0 DOES  COMPLETE  ! NO  INTERRUPT; 


FETCH 

1)  MAR<-PC 

2)  DATA!REn<-MEMORY  (1) 

3)  PC<-PC  +1  (1) 


INTERRUPT 

1)  MAR<-0 

2)  MEMORY<-PC  (1) 

3)  MAR<-MAR  + 1 (2) 
H)  PC<-MEMORY  (3) 


END 


Fip  2.H 

A colleotion  of  connected  blocks 
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q 

0PEPATI0N!CHF.CK!0FF.  The  statement  number  for  this  tvoe  of 
statement  should  be  zero;  otherwise,  a mystery  Warnine  me^SiartKe  will 
appear  which  reflects  a mistake  which  actuallv  Wasri't  made.  The 
control-stmts  may  appear  anywhere  within  a VJPPOC  or  PPOC  block 
without  affectirip  the  execution  or  statement  ordering. 


no  order-info  ia  uaed,  which  meana  the  CHFCKPOINT  will  be  executed 
imned lately  ori  entering  the  block.  The  order-info  tella  the 
trarialator  to  put  CF'ECKPOTNT  code  after  every  atatement  appearine  in 
the  order  irjforrpation  liat. 

Several  deaign  lantruagea  uae  regiater  trariafer  atatementa  aa 
their  baaic  atatemetit  type,  but  the  degree  of  complexity  of  the 
remiater  tranafer  atatementa  differa  greatly  among  the  deaieri 
latiguagea[Bar75,nul] . We  are  limiting  the  regiater  tranafera  to  be 
either  utiary  or  binary  operationa,  thua  preventing  complex  regiater 
tranafer  atatementa.  We  feel  that  thia  ia  cloaer  to  a "true" 
deacriptiori  of  a digital  ayatem,  and  more  importantly,  cloaer  to  the 
actual  conatruction  of  the  digital  ayatem.  Complex  boolean 
atatementa  are  permitted  but  they  muat  be  handled  in  a apecial 
manner  when  building  the  data  base,  which  will  be  dlacuaaed  in 
Chapter  3. 

There  are  aeveral  problema  unique  to  an  aaynchronoua  dii^ltal 
ayatem  deaign  and  thia  deaign  language  in  particular.  Theae  are 
diacoveriruT  hangupa  in  the  CS,  inauring  that  the  atatementa  form  a 
partial  ordering,  aerializing  the  atatementa  for  execution  ,and 
iriauring  that  the  data  atructure  ia  determinate. 

Hangupa  are  analogoua  to  deadlocka  in  operating  ayatema.  To 
look  for  theae,  we  muat  determine  if  any  direct  cyclea  exiat  in  the 
directed  graph  repreaenting  the  inter-block  ( INTER ! BLOCK) 
connectlona.  For  the  intra-block  atructure  we  muat  determine  if  the 
atatementa  form  a partial  ordering.  There  are  aeveral  methoda  for 
detecting  theae  direct  cyolea[ Joh ,Knu ,Vud75 ] ; we  ohoae  to  uae  a 
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method  Called  the  topological  aort[Knu].  We  muat  alao  be  able  to 
aerialize  the  iritra-block  ordering  for  execution.  Thia  taak  ia  alao 
done  by  the  topological  aort  routine. 

Aa  arj  example,  if  the  atatementa  aren't  iri  a partial  ordering 
the  following  could  occur; 

2)  A<-B  (3) 

C<-D  (2) 

which  aaya  atatement  2 ia  to  be  executed  after  atatement  3 but 
atatement  3 ia  to  be  executed  after  atatement  2.  Thia  would  reault 
in  a hangup;  CauairiP  the  eritire  block  to  be  ienored,  and  a null 
procedure  to  be  (renerated  for  thia  block. 

The  biggeat  and  noat  intractable  problem  reault  irifr  from 
aaynchronoua  deaign  ia  that  of  teating  for  determiniam.  A ayatem  ia 
determinate  if  the  reault  of  the  computation  dependa  uniauely  on  the 
initial  coritenta  of  the  atorage  elementa  for  ariy  execution  aequence 
that  doea  not  violate  the  proceaa'a  ordering[Cof ] . 

A ayatem  ia  non-determinate  if  one  of  the  following  three  caaea 
occura:  read  after  write,  write  after  read,  or  write  after  write. 
The  read  after  write  or  the  write  after  read  caae  occura  when  for 
concurrent  inatruct iona  i and  j,  i reada  from  a region  and  J writea 
into  the  aome  region.  In  write  after  write  concurrent  inatruct iona, 
i and  j write  into  the  aame  region[Cof , Pet ] . Since  all  theae 
operationa  are  aaynchronoua  and  concurrent,  the  ayatem  can't 
guarantee  that  the  aequence  of  operationa  will  be  the  aame  every 
time  the  block  ia  executed.  Therefore,  the  reaulta  in  the  above 
Caaea  would  be  non-determinate.  We  are  currently  inveatigating  two 


1? 


different  testa  for  determinism. 


The  first  test,  which  would  be  easit*st  to  implement,  creates 
two  simulators.  Orie  simulator  executes  all  concurrencies  that 
appear  in  a block  from  left  to  ri(?ht,  and  the  other  simulator 

executes  these  same  concurrencies  iri  the  opposite  or'der  (ripht  to 
^ left),  thus  reversirig  the  order  of  executiori.  By  checkins  the 

^ Output  visually  the  user  determines  if  there  is  a difference  iri  the 

j"  outputs,  which  would  indicate  that  the  desien  is  nori-determinate. 

The  visual  inspeotiorj  is  one  of  the  method's  major  drawbacks.  If 
the  network  is  non-determiriate  the  problem  is  locat  ins  this 
rjori-determinism.  To  do  this,  the  user  must  move  outout  statements 
arourid  uritil  the  sroup  of  statemerits  forming  a coricurrency  which 
r Caused  the  oroblemCs)  is  oinpointed.  Thus,  this  method  is  sood  for 

^ quickly  detecting  non-determitiisra  but  not  for  looatins  it. 


I 
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The  other  possible  solution  is  achieved  by  forming  "read"  sets 
and  "write"  sets  which  corjtain  the  elements  of  the  right  and  left 
Part  of  the  assignment  expressions  respectively.  Then  the 
intersection  of  the  "read"  and  "write"  sets  where  the  concurrencies 
appear  is  examined [Cof] . If  it  is  not  null,  the  cause  of  the 
non-determinism  is  identified.  We  have  mlossed  over  much  of  the 
detail  in  this  approach.  The  aporoach  is  excellent  for  locatinR  the 
Cause(s)  of  non-determinism. 

In  choosing  a programmint?  language,  we  had  a choice  from  a 
large  collection  of  lariKuaetes:  f^’ORTRAN,  ALGOL,  SAIL,  PASCAL,  and 
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manipulate  linked  lidta  would  be  a rjeoedaity.  This  immediately 
eliminated  FOPTPAN  afjd  ALGOL.  PASCAL  Waa  eliminated  beoauae  ita  I/O 
waa  not  flexible  enough.  SIMULA  waa  eliminated  ainoe  there  waa 
little  avatema  backup  if  oroblema  were  etjooutitered  with  the 

language.  Thia  left  SAIL  [Pei]  which  turned  out  to  be  an  excellent 

choice.  SAIL  haa  very  powerful  afjd  flexible  I/O,  excellprjt 

) character  hatidling,  atra i^ht  forward  record  m.atiipulat  ioti , and 

excellent  macro  Pacilitiea.  The  record  atructure  waa  uaed  to 
imclement  the  linked  liat  atructure  for  the  topological  aort 

routine.  Heavv  uae  waa  made  of  the  macro  facility  throughout  the 
tranalator  to  Parameterize  it;  moat  of  the  code  we  generate  for  the 
aimulatora  ia  in  the  form  of  macroa.  M^^croa  along  with  conditional 
compilation  enabled  ua  to  tailor  the  aimulator'a  code  and  make  it 
much  more  efficient. 

( 

\ 
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Chapter  ? 

DATA  STRUCTIIRF 

Iti  order  to  simulate  reeister  trariafer  operatioria,  there  muat 
be  data  elP^ento  ori  which  operatioria  Cari  be  perfortned.  Thia  raiaea 
the  problema  of  how  to  deterrrine  the  data  elementa,  how  to  declare 
them,  atid  how  to  repreaent  them.  Theae  problema  will  be  diacuaaed 
in  the  reat  of  thia  chapter.  We  will  alao  diacuaa  the 
implementation  of  the  data  baae  and  the  aieni f icarice  of  the  data 
baae  entriea.  Laatly,  we  will  look  at  the  procedure  INTEGRITY  which 
checka  the  data  baae  to  inaure  that  it  ia  error  free. 

A data  baae  aervea  two  purpoaea.  It  eatabliahea  the  width  of 
the  data  patha  and  the  data  type  of  each  element.  The  data  baae  in 
combination  with  reeiater  trariafer  atatementa  impliea  the  data 
atructure  (DS),  which  ia  the  entity  on  which  the  aimulation  ia 
baaed . 

A data  baae  ia  Created  by  a aeriea  of  declarationa  which  bind 
object  riamea  to  data  element  typea.  Theae  atatementa  are  analoeoua 
to  declaration  atatementa  in  moat  proerammine  lanmuacea. 

There  ia  a rich  variety  of  data  elementa,  allowine  the  deaigner 
a great  deal  of  flexibility.  In  the  near  future,  hardware  will 
replace  many  functiona  now  performed/aimulated  in  aoftware, 
(apecifically , parta  of  the  operatirur  ayatem  [Chu72b ,Chu77 ,Smi] ) . 
Thua,  mariy  of  the  elementa  allowed  in  thia  D.S  will  become  a 
neceaaity  in  future  deaifrna. 
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The  Tioat  baaio  data  element  ia  the  refiater; 

Rf^ulSTRR  Name  (width) 

where  Name  is  the  repiater'a  name  and  "width"  ia  the  width  of  Name 
iri  bita,  not  to  exceed  aome  maximum  width. 

A uaeful  elerront  ia  the  named  aubfield,  which  allowa  the  uaer 
to  name  a particular  aubaet  of  contiguoua  bita  within  any  other  data 
element . 


SUBFIELD  Namel  (width)  OF  Name?  ( beeirmitiP-point ) 

Name!  ia  defined  to  be  a aubfield  of  Name?,  where  Narel  atarta  at 
bit  beffinnini^-point  in  Name?  and  ia  "width"  bita  wide,  the  bita  are 
numbered  right  to  left,  with  the  rightmoat  bit  being  numbered  zero. 
The  aubfield  idea  ia  extended  to  aeveral  of  the  other  declarationa 
by  prefixine  the  "regular"  declaration  atatement  with  "aubfld"  to 
indicate  that  thia  declared  element  ia  a aubfield  of  aome  other 
element.  Thia  allowa  the  uaer  to  apecify  that  certain  aubfielda  of 
a larKer  field  have  a apecific  function. 

A declaration  that  generatea  more  than  one  element  la  a member 
of  Vector-claaa,  which  includea  MEMORY,  STACK,  and  QUEUE. 

Veotor-claaa  Name  (aize)  (width) 


Name  ia  defined  to  be  a member  of  Vector-claaa  with  "aize"  elements 
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(0  to  size-1),  with  each  element  "width"  bits  wide. 

To  stet  around  some  of  the  limitations  that  were  imoosed  on 
register  transfer  statements,  we  have  a declaration  called  DEFINE. 
DEFINE  creates  a function  which  allows  only  the  boolean  operators 
and/or  the  concatenation  operator. 

DEFINE  Name  = onni  odI  opn?  od,1  opnk 

Thus,  Name  can  be  defined  to  be  an  arbitrarily  complex  boolean 
function  or  a collection  of  different  fields  concatenated  tosether. 
The  operator  precedence  is  the  same  as  SAIL's  operator  precedence. 
Name  can  now  be  used  Just  as  any  named  register  would  be  used  in  a 
register  transfer  statement.  A width  for  Name  is  calculated. 

An  important  data  element  is  the  MEM! ADORER,  which  is  the  only 
link  to  a MEMORY  data  element.  The  value  of  the  MEM! ADORER 
associated  with  some  memory  element  is  used  to  index  into  this 
memory  for  read/write  operations.  There  is  no  other  way  to  access 
memory,  so  if  some  data  elements  are  declared  to  be  MEMORYs  then 
there  must  be  a MEM! ADORER  associated  with  them  or  an  error  will 
occur. 


MEM! ADORER  MAR(16)  FOP  MEM1 ,MEM2 
SUBFLDIMEMIADDRER  MARICACHE(8)  TO  PC(12)  FOR  CACHE 


MAR  is  declared  to  be  16  bits  wide  and  associated  to  MEM1  and  MEM2, 
which  must  be  MEMORYs  or  an  error  will  occur.  MARICACHF  is  declared 
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to  be  an  8 bit  wide  subfield  of  PC  and  associated  to  CACHE. 

After  a retrister  transfer  operation  takes  place,  how  can  the 
desif^n  check  the  result  of  the  operation  or  check  if  an  error 
occurred?  This  brin<^s  up  the  concept  of  dependency,  for  which  there 
are  two  types.  The  first  dependency  is  based  on  the  data  elements 
involved  in  the  register  transfer.  If  the  object  is  dependent  upon 
another  object  of  data  tvne  STACK  or  QUEUE  then  whenever  stack/oueue 
is  involved  in  an  operation  its  dependent  variable  is  set  to  reflect 
whether  the  stack/oueue  overflowed,  underflowed,  or  remained  within 
its  limits. 

DEPIVAR  Namel  (widthi)  FOP  Name? 

Namel  is  declared  to  be  dependent  on  Name?;  for  Name?  to  have  anv 
effect  on  Namel  then  Name?  must  be  either  a STACK  or  a QUEUE. 

The  second  type  of  dependency  is  based  on  the  operation's 
result.  This  dependent  variable  can  be  set  to  indicate  the  result 
of  an  operation,  if  OPERATION ICHFCK ION  switch  has  been  previously 
set.  The  switches  will  nave  no  effect  if  no  variable  has  been 
declared  to  be  operation  dependent.  After  the  operation  two 
segments  of  code  will  be  generated  to  set  the  correct  bits  in  the 
operation  dependent  variable.  One  senment  of  code  tests  and  sets 
for  overflow,  and  the  other  sewnent  tests  for  positive,  negative,  or 
a zero  result.  The  designer  need  not  use  this  "feature",  but  can 
implement  his  own  design  to  check  for  these  conditions,  if  so 
desired . 
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OP'^RATlONiCMK  NaireKU) 

SU”FLD!OPFR!CHK  N'ame?('0  TO  'Jrt'ne8(?) 

Natr.<-’1  ia  declared  to  be  U bito  wid^  arid  operation  dependent.  Name? 
id  declared  to  be  U bito  wide  arid  a aubfie]d  of  t’aire'?.  if  niore  than 
orie  elenerit  id  declared  to  be  operation  dependent,  otily  the  ficdt 
will  be  Uded. 

A srroup  of  deolaratiori  dtatenentd  id  predented  in  8.1. 

In  or'der  to  implement  the  data  bade,  there  mudt  be  dOme 
uriiverdal  way  to  create  deacriptord  for  each  deolaratiori . Three 
routined  are  uaed  to  create  new  dodcriptord.  They  are  DATAIPLOCK, 
NAMING,  and  INSERT ! NAMF ! TYPE . Theae  routined  dCt  up  the  deacriptord 
atid  then  call  other  routined  to  collect  further  informatiori  to 
complete  the  dedcriptord. 

We  ude  two  arvaya  ID.'LIST  and  SYMBOLITAPLE  aa  the  data  bade. 
They  are  both  indexed  by  a hadh  number  that  id  venerated  by  a 
hadhirig  function  (HASHIFUNCT)  which  uded  the  object'd  name. 

ID! LIST  had  the  character  dtririR  repreoentins  the  object'd 
name.  SYMBOL ! TABLE 'a  entriea  hold  all  the  other  informatiori 
concerninif  the  object.  The  entriea  are  affected  by  the  data  tyoe  of 
the  object.  The  firat  entry  in  SYMBOLfTAELE  ia  alwaya  the  object'd 
data  type  (STACK  ,REGI.STER, SUBFIELD) . The  aecond  entry  ia  either  the 
hadh  number  of  the  dependent  Variable  for  atacka  and  queuea  or  the 
haah  riumber  of  the  field  of  which  the  object  ia  a aubfield.  The 


third  element  la  either  the  aize  of  the  Vector-claaa  or  the  bit 


REGISTER  RUN(1) 


REGISTER  INSTR!WRD(4) 

REGISTER  PAGE!ADDR(i4) 

STACK  STK  (10)  (12); 

DEPIVAR  A(2)  FOR  STK; 

MEMORY  M(102U)  (12)  ; 

MEM!  ADORER  MAR(2!<)  FOR  M ; 

REGISTER  DR(36); 

SUBFIELD  DRK12)  TO  DR(0)  ; 

SUBFIELD  DR2(12)  TO  DR(12); 

REGISTER  STATUS1WRD(20) 

SUBFIELD  POSINEGd)  TO  STATUSIWRD(  17  ) 

SUBFIELD  ZEROd)  TO  STATUS!WRD(16) 

SUBFIELD  PC(16)  TO  STATUS!WRD(0 ) 

SUBFLDIOPERICHK  OVFLW!iiIT(1)  TO  STATUS!WRD(18 ) 
DEFINE  BOOL=(  B OR  C)  4 E; 

DEFINE  ADDRESS:  PAGE&PC; 

Fig  3.1 


A collection  of  declarations 


location  where  the  dubfield  will  start.  The  fourth  entry  is  the 
width  of  the  object  in  bits  (fields  are  numbered  risht  to  left  with 
the  first  bit  being  zero).  The  fifth  arid  last  erjtrv  holds  the  hash 
number  of  the  object  which  acts  as  a memorv  address  regist^rCMAP ) 
for  a specified  MEMOPY(s).  All  the  entries  irj  the  table  for  any  orie 
object  aT'e  generally  not  used,  allowiric  for  future  exparisiori. 

The  last  procedure  to  deal  with  the  data  base  is  Called 
INTEGRITY.  INTEGRITY'S  job  is  to  go  through  the  data  base  and 
insure  that  it  is  self  corisistent.  There  are  seyeral  problems  that 
INTEGRITY  searches  for.  First,  it  checks  that  all  poiriters  ooint  to 
yalid  elements  and  that  they  don't  poirit  back  ori  themselyes. 
Secorid , it  checks  to  see  if  certain  data  types  meet  a minimum 
requirement  for  width;  dependent  yariables  for  STACKs  and  OUEUEs 
must  be  at  least  two  bits  wide.  Third,  it  checks  if  Vector-class 
elements  haye  their  associated  yar'iable.  For  instance,  all  memory 
elements  must  haye  a MEM! ADORER  associated  with  them;  STAGKs  and 
OUEUEs  must  haye  a dependent  yariable  for  error  conditions. 

This  coyers  the  procedure  DATA! BLOCK  which  oyersees  all  of 
these  actiyities.  DATAIBLOCK  is  the  controlling  procedure  which 
contains  seyeral  other  routines.  These  routines  assist  DATAIBLOCK 
in  creating  the  data  base  and  checking  for  consistency. 
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Chapter  4 

SYNTAX  ANALYSIS  AND  CODE  GENERATION 

In  this  chapter  we  will  discuss  the  last  two  major  components 
of  the  translator  which  venerates  the  simulators.  These  are  the 
syntax  analyzer  and  code  erenerator. 

Let  us  first  look  at  the  implementation  of  syntax  analysis, 
which  checks  the  input  to  see  if  it  is  leyal.  If  there  is  an  error 
in  the  input,  various  error  recovery  schemes  are  tried  so  that 
parsini^  can  continue  [Rau,Tin,Wil] . If  the  error  recovery  attempt 
fails,  the  whole  program  is  aborted  and  no  simulator  is  eenerated. 

The  parser  that  does  this  syntax  analysis  is  driven  by  a slate 
table  (STATEITAPLE)  . .STATE!TAPLE  was  eenerated  from  the  state 
diavram  in  Fiy  4.1a.  States  17  and  18  are  missing  from  the  state 
diagram,  havine  been  deleted  by  standard  .'^tate  reduction  methods. 
Inrut  to  the  state  table  consists  of  the  previous  state  of  the  table 
and  the  tokenised  Input  (Fiv  4.1b), 

A scanner  reads  the  input  and  breaks  it  into  meaningful  mpoups 
of  characters  (names,  symbols,  numbers,  etc.).  The  scanner  then 
classifies  each  yroup  of  characters  with  a classification  technioue, 
with  the  final  result  being  a tokenised  input. 

Selectinff  the  next  state  and  dolnm  error  recoverv  is  the 
function  of  a procedure  called  STATE  I MACHINE.  The  output  from 
STATE IMACHINE  is  either  the  next  state  or  the  number  zero, 
indicating  an  error  from  which  recovery  is  not  possible  (terminal 


error) . 
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TOKENS  INPUT 


Identifiera. 

key 

= 

Keyworda  except  "DO". 

kgyi 

= 

The  keyword  "DO". 

num 

= 

Numbera. 

bita 

= 

Binary  numbera  (only  0 

a eifid  1 d) 

act 

= 

Operatora  ( AND, 

SHL). 

rel 

= 

Binary  relations  (<,  > 

, >=,  <>). 

brk 

r 

Symbola  "("  or  ")". 

brki 

= 

Symbol  " , " . 

del 

r 

End  of  the  line  (cr  or 

II  • ti  \ 

1 • • 

iiiiii 

= 

End  of  the  input. 

FiR  4.1b 

Toketia  and  their  correaponding  input  charactera 

r* 

r 

\ 

] 
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A variety  of  error  recovery  scheaies  1?  tried  dependinor  on  what 
type  of  error  occurred.  SoTie  of  our  methods  may  appear  draconian, 
but  this  simplifies  the  error  recovery.  One  method  is  to  flush  and 
ignore  the  current  line  and  then  to  create  a dummy  line  of  input 
that  the  parser  will  accent,  thereby  allowing  the  parser  to 
continue.  However,  with  the  straightforward  erammar  and  syntax 
structure  of  the  DL,  the  use  of  such  harsh  methods  should  be 
infrequent . 

The  parser  itself  is  very  straightforward.  It  consists  of  a 
large  CASF.  statement  whose  index  variable  is  the  next  state  of  the 
state  table.  This  CA.SE  statement  is  within  a large  loop  which  loops 
until  either  the  end  of  the  input  is  reached  or  a terminal  error 
occurs.  The  action  of  the  parser  can  most  easily  be  followed  by 
tracing  through  its  actions  with  the  state  diagram  (Fig  4.1).  The 
parser's  documentation  will  explain  the  actions  at  each  state. 

The  parser  works  on  a block  by  block  basis,  where  each  block  is 
translated  into  a SAIL  procedure.  At  the  entrv  to  each  block,  the 
parser  calls  a routine(ENDIOFIBLOC<)  that  checks  the  ordering  of  the 
previous  block,  serializes  the  block's  basic  statements  and  outputs 
them.  Then  another  routine  (NEWIPLOCK)  will  initialize  some  kev 
variables  in  preparation  for  parsing  the  current  block  . 

At  the  entry  to  each  block,  the  parser  first  determines  the 
type  of  block  (PROC,  WPROC,  or  DPROC).  The  WPROC  and  DPROC  blocks 
require  some  extra  code  (the  block's  preamble)  to  be  generated  at 
the  beginning  of  the  procedure.  In  the  case  of  the  WPROC,  a WHILE 
loop  is  created  with  the  predicate  and  a counter  which  controls  the 
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loop,  to  prevent  infinite  looping. 

The  parser 'a  code  ia  generally  straightforward  with  most  of  it 
i given  to  checking  iriput  legality.  The  onlv  place  the  codine  is 

awkwat’d  is  in  the  handlirig  of  the  statements  for  the  PPPOC.  They 
are : 

binary-number  DOES  Proc-Call 
binary-number  DOES  COVPLETS 
NO^JE  DOES  Proc-call 
NONE  DOES  COMPLETE. 
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If  there  is  more  than  one  NONE  statement,  we  ignore  all  but  the 
first.  Generally  code  is  gerierated  on  a statement-by-statement 
basis,  but  code  is  not  generated  for  a NONE  statement  at  this  point 
in  parsing;  instead,  we  wait  until  the  entire  block  is  written  out 
and  then  generate  some  closing  code  called  the  DECODE! POSTAMBLE. 
This  postamble  generates  the  appropriate  code  for  the  NONE 
statement.  If  a NONE  statement  does  not  occur  in  the  DPROC,  code 
will  be  generated  to  Catch  values  that  are  not  covered  by  the 
DPROC 's  statements,  and  an  error  message  will  be  displayed. 

Two  different  types  of  code  are  generated.  One  type  of  code  is 
tailored  for  the  DPROC  statements  and  the  other  type  of  code  is  for 
the  register  transfer  and  proc-call  statements  in  the  WPROC  and  PROC 
blocks. 


The  code  Kenerated  for  the  DPROC  atatements  Waa  bdaically 
covered  in  the  preceding  oaragrapha,  ao  we  will  not  diacuaa  the 
DPROC  atatemetita  ariy  further.  We  will  dlao  ienore  code  generatiori 
for  the  proc-Call  airice  it  ia  very  aimple.  Iriatead,  we  will  look  at 
the  more  intereatine  arid  difficult  problema  of  (feneratinir  tif'ht  code 
for  reiriater  trariafer  atdtemerita.  Rirat,  aotne  terminoloR'v  ia 
needed.  The  element  on  the  left  hand  aide  of  the  aaaignment  will  be 
Called  the  "object"  or  the  "object  of  the  aaaignment".  Poth 
operanda  will  be  called  operanda  with  no  diatinction  made  between 
them.  The  term  "reault"  ia  uaed  to  indicate  the  value  generated  bv 
an  operation,  arid  a temporary  reault  ia  a temporary  that  haa  been 
generated  with  the  value  of  the  "reault".  "Vector"  will  be  uaed  to 
denote  any  member  of  Vector-claaa. 

Before  code  Can  be  aerierated  for  a abatement,  aeveral  checka 
rauat  be  made.  Firat,  are  there  aufficient  operands  for  the  operator 
and  Can  the  operation  cauae  an  overflov/?  .Second,  are  the  operanda 
and  object  aubfielda?  If  ao,  will  we  need  to  penerate  intermediate 
reaulta?  Third,  are  the  data  paths  of  sufficient  width  for  the 
operation?  (A  7 bit  result  cannot  he  put  in  a bit  object  field.) 

There  are  four  routines  associated  with  code  generation: 
MACROINAME,  OPNICHK,  WRTIREGITRF,  and  OBJIGEM. 

MACROINA’-’E  is  very  aimple;  it  is  passed  the  operator  and 
returns  the  name  of  the  macro  that  performs  the  operation,  the 
number  of  operands  required  by  the  operator,  and  a flap  indicating 
if  the  operator  Can  cause  an  overflow. 
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OPNMCHK  ia  Oall<“d  from  the  pdraer;  ita  input  ia  a re^iater 
trariafer’  operand.  OPNICHK  makea  aome  deoiaiorja  oonoerninp  the 
ooer’and,  which  could  be  a aubfield,  a vector,  or  a recriater.  If  the 
operand  ia  a aubfield,  the  aubfield  muat  be  extracted;  if  the 
operand  ia  a vector  a futiction  for  handling  thia  claaa  of  elementa 
muat  be  venerated.  The  output  of  OPNICHK  ia  a atrinp  that  ia  uaed 
directly  aa  arj  operarid  for  the  .macro  venerated  by  MACROIN'AMF.  The 
atrine  will  belorig  to  one  of  three  categoriea.  If  the  operand  ia  a 
aubfield,  a temporary  ia  aaaigned  to  the  extracted  field  and  the 
riaTe  of  the  temporary  ia  returned.  If  the  operand  la  a vector,  a 
functiori  that  handlea  thia  type  of  data  element  ia  returned.  (There 
are  at  preaent  three  vroupa  of  functiona.  Each  vroup  haa  a function 
that  retrievea  an  element  and  inaerta  an  element.  VEVOPY,  STACK  and 
QUEUE  each  have  a vroup  (2)  of  functiona  aaaociated  with  it.)  If  the 
operafid  ia  a reviater,  the  operand  ia  returned  with  ori«» 
modification;  the  operand  ia  ANDed  with  a "onea"  raaak  to  extract 
the  prooer  aize  bit  field. 

WPT!REC!TRF  haa  the  job  of  firat  checking  to  aee  if  the  data 
path  requirementa  are  met  and  aecondly  to  call  ORJIGEM.  WRTIPEGITRF 
will  take  the  operator  name  and  concatenate  it  with  the  operanda  to 
form  a macro  which  ia  oaaaed  to  OP.JIGEV.  It  will  alao  oaaa  the  haah 
number  of  the  object,  a awitch  indicating  if  the  operation  Can  Cauae 
an  overflow( OVER! FLO) ) , and  a awitch  Indicating  if  the  right  hand 
aide  expreaaion  ia  "aimple"  or  not  (.SIMPLE!  OP ) . 


28 


ORJIGEN  does  the  same  as  OPNICHK  except  that  it  works  on  the 
object  and  not  the  operands.  OBJfOFN  will  venerate  code  similar  to 
that  of  OPNICHK,  deoendint^  on  whether  the  object  is  a subfield, 
vector,  or  a rezlster.  The  SII^PLFIOP  and  OVERFLOW  switches  are  used 
to  minimize  the  amount  of  code  venerated.  If  .SIVPLEIOP  is  on,  no 
"temporary  result"  is  venerated.  If  the  OVERFLOW  switch  is  on,  then 
when  ^eneratinv  code  to  set  status  conditions,  the  overflow  checking 
code  will  be  venerated. 

Looking  at  the  process  as  a whole,  we  see  that  OPNICHK  will 
receive  each  operand  and  return  either  a strln?  with  the  modified 
operand,  the  name  of  a temporary  where  the  operand's  current  value 
now  resides,  or  a function  for  properly  accessing  the  element. 
MACROINAME  will  take  the  operator  and  return  its  associated  macro 
and  some  switches.  WRTIREGITRF  will  concatenate  the  macro  name  and 
the  operands  to  form  a macro  representing  the  ri^ht  hand  side  of  the 
statement.  This  will  be  passed  to  OBJIGEN,  which  will  venerate  the 
final  code  for  the  register  transfer  statement  and,  in  some  cases, 
code  to  set  status  conditions. 

This  concludes  the  discussion  of  syntax  analysis  and  code 
(feneration  for  the  individual  blocks.  Next  we  consider  in  what 
order  we  output  the  code  for  execution.  .Since  we  have  a serial 
machine,  all  the  parallelism  within  a block  must  be  serialized  for 
execution  without  violating  the  ordering  that  was  declared.  This 
brings  forth  the  second  problem:  insurinv  that  the  statements  form 
a partial  ordering. 
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Uainp:  the  routine  TOPOLOriiCflL ! .'^OPT , we  teat  if  the  atatementa 
for  the  current  block  form  a partial  ordering.  Thia  routine  returna 
in  MAPPKR  the  atatement  numhera  in  a total  ordering  without 
violating  the  oriiririal  partial  ordering.  If  a partial  ordering  doea 
not  exiat,  code  for  thia  block  ia  tiot  outputted,  and  the  routirie 
returrja  a "falae"  value  which  ia  AMDed  with  previoua 
300r ! BLOCK ! ^ 'a , thua  any  incorrect  block  will  Cauae  GOOD ! BLOCK  ! 
to  be  falae.  If  the  block  ia  ayntactically  correct,  WPITE!OUT!BLOCK 
ia  Called  to  output  the  code  and  the  checkpointa.  Thia  will 
coritinue  uritil  the  end  of  the  input  ia  encountered. 

Next  we  check  the  inter-block  connectiona,  INTEPIBLOCK,  to  aee 
if  any  direct  cyclea  exiat.  TOPOLOGICAL ! .SORT  ia  alao  uaed  to  check 
thia  ordering.  If  direct  cyclea  exiat,  PGMISW  ia  aet  to  falae.  If 
direct  cyclea  do  not  exiat,  we  write  out  the  laat  linea  of  code  for 
the  aimulator.  We  muat  check  if  the  aimulator  haa  been  improperly 
generated.  Thia  ia  done  by  ANDing  OOOD!  BLOCK  !?W  and  PGMiSiV 
together.  If  the  reault  ia  falae,  a nonrecoverable  error  occurred 
and  the  aimulator  ia  deatroyed.  If  the  reault  ia  true,  a aimulator 
haa  been  generated.  The  SAIL  compiler  compilea  the  aimulator  and 
executea  it.  At  the  end  of  the  execution,  we  have  the  aimulaticn'a 
execution  time  output  and  the  aimulator,  which  the  uaer  can  now  run 
at  any  time. 
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Chapter  5 
DKSIGM  RXAMPLF: 

In  this  chapter  we  will  lool<  at  a desl«^n  exanple  which  was 
developed  and  tested  uslne  the  translator. 

Ihe  desif^n  Is  a simple  computer  called  the  Sinrle  Instruction 
Nachlne  (SIM).  As  SIM's  name  Implies  It  executes  a slnvle  subtract 
and  test  Instruction,  SU6TST  A,  B,  P , see  top  of  FIk  5.1.  The 
machine  has  been  thorouathly  described  In  two  previous  articles  by 
Mudge.  The  only  changes  made  have  been  the  addition  of  a data 
structure  and  the  insertion  of  a checkpoint.  This  is  not  the  only 
DS  possible;  for  example,  it  could  have  easily  been  made  16  bits 
wide  rather  than  12  bits  wide  a.s  chosen  here. 

Fig  5.1  is  the  program  which  SIM  will  execute  as  a test 
program.  The  program  calculates  the  Fibonacci  sequence  until  the 
WPROC's  built  in  counter  reaches  its  predetermined  value  and  stops 
looping  (see  page  24).  The  program  is  loaded  into  memory  via  the 
IMITIALIZB  statement;  other  key  variables  PC  and  RUN  are 


initialized 

in 

the 

same  way.  Fig 

5.2 

is  the  input 

to 

the 

translator. 

Fig 

5.3 

is  the  simulator 

that 

was  generated 

by 

the 

translator,  and  Fig  5.4  is  the  simulator's  outputd.e.  the 
simulation),  which  is  generated  by  the  CHECKPOINT.  When  the  PC  is 
equal  to  2 and  5 the  DR  is  a calculated  Fibonacci  number.  At  the 
other  locations  DR  has  intermediate  results.  The  PC  Is  written  out 
after  the  PC  has  been  incremented  therefore  this  does  not  conflict 
with  the  test  program  which  shows  the  Fibonnaci  number  belne 
calculated  at  locations  1 and  4. 


SIM 

A oinple  intruotion  machine 


SLIBTST  A,  E,  P 

1.  A<-  C[A]  - C[P] 

2.  IF  C[A]  = 0 THEN  PC<-C[P] 


LOG 


0 

LOOP: 

SUBTST 

ZERO.B 

! ZERO<— B 

1 

SUET ST 

A, ZERO 

! A<-E  - ZERO 

2 

SUETST 

ZERO, ZERO, NEXT  ! ZERO<-ZERO-ZERO 

3 

NEXT: 

SUBTST 

ZERO, A 

! ZERO<— A 

SUBTST 

B,ZERO 

! B<-B-ZERO 

5 

SUBTST 

ZERO, ZFRO, LOOP  ! ZERO<-ZERO-ZERO 

6 

ZEPOrO 

! ZERO  IS 

A CONSTANT 

7 

A=1 

! INITIAL 

VALUE 

8 

B=1 

! INITIAL 

VALUE 

Fig  5.1 

Program  to  calculate  the  Fibonriaci  aequence 
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SIM 

DATA  STRUCTURE  and  CONTROL  STRUCTURE 


INITIAL  104, 118, 870,103, IB'J.IO?, 0, 1 ,1  ; 
MEMORY  M(16)  (12) 

MEM! ADORER  MAP(12)  FOR  M 


INITIAL  ON; 

REGISTER  RUNd  ) 

REGISTER  INT(I) 

REGISTER  IR(12) 

SUBFIELD  IRP(4)  TO  IR(8) 
SUBFIELD  IRA(4)  TO  IR(4) 
SUBFIELD  IRB(4)  TO  IR(0) 

INITIAL  0; 

REGISTER  PC(4) 

REGISTER  DR(12) 

REGISTER  DRK12) 

REGISTER  DR2(12) 

REGISTER  A(12) 

REGISTER  IPA(12) 

REGISTER  IP(12) 

BLOCK  SIM; 

BLOCK  DECI 
BLOCK  FETCH 
BLOCK  EXEC 
BLOCK  INTR 
BLOCK  DEC 
BLOCK  BR 

ENDIDATA 

SIM 

WHILE  TRUE  DO 

1)  DECI 

2)  FETCH  (1) 

3)  EXEC  (2) 

DECI 

DECODE  INT  AS 


1 DOES  INTR 
0 DOES  COMPLETE 


INTR 

1 ) MAR<-IPA 
?)  DR<-IP 
3)  M<-DH  (1,2) 

PrTCri 

I ) MAR<-PC 

2)  DR<-M  (1 ) 

3)  PC<-INC  PC  (1  ) 

EXCC 

1)  IR<-DR 

12)  DEC  (10,11) 

I I ) M<-DR  (8,9) 

2)  MAR<-IRA  (1  ) 

3)  DR<-M  (2) 

R)  DRK-DR  (3) 

5)  A<-DR  (3) 

6)  MAR<-IRP.  (3) 

7)  DR<-y  (R,S,6) 

8)  DR<-A  -DP  (7) 

9)  MAR<-IRA  (7) 

10)  DR2<-DR  (8) 

0)  CHKPT  DR, PC  (12) 

DEC 

DECODE  DR  AS 
0 DOES  PR 
NONE  DOES  COiRPLETE 

PR 

1)  DR<-PC 

2)  PC<-IRP  (1 ) 

3)  MAR<-PC  (2) 

U)  DR<-M  (3) 

END 


Fij?  5.2 

Desi??n  example  for  SIM 
input  to  the  translator 


( 


►^KGIN  "MAIN" 

RrCUIHF  "MACROS. SAI"  SOURCK! FILF ; 

REOUIRF  "DCL.SAl"  SOURCEIFILE; 

RHRLOADlKITri  1 0U  , 1 1 8 , 870 , 1 03 , 1 S'* , 10?  ,n  , 1 , 1 ; 

INTcGFR  array  ''[0:16]; 

INTEGER  M/ip; 

INTFGKP  RUN; 

INTFGFR  INT; 

INTFGPP  IR; 

INTEGER  PC; 

INTEGER  DR; 

INTEGER  DR1; 

INTEGER  DR2; 

INTEGER  A; 

INTEGER  IPA; 

INTEGER  IP; 

FORWARD  PROCEDURE  SIM; 

FORWARD  PROCEDURE  OECI ; 

FORWARD  PROCEDURE  FETCH; 

FORWARD  PROCEDURE  EXEC; 

FORWARD  PROCEDURE  INTR; 

FORWARD  PROCEDURE  DEC; 

FORWARD  PROCEDURE  BR; 

REQUIRE  "FUNC.SAI"  SOURCEIFILE; 


PROCEDURE  SIM; 

BEGIN  "SIM" 

PROCESS !NAME<-"SIM"; 
WPPOC!PRE(TRUE  ); 

DECI; 

FETCH; 

EXEC; 

WP ROC! POST amble 
RETURN; 

END  "SIM"; 

PROCEDURE  DECI; 

BEGIN  "DECI" 

PROCESS !NAME<-"DECI"; 
DECODE ! PREAMBLE ( I NT , 0 , 1 ) ; 
DECODEfSTd ,INTR,0); 
DECODE! ST(0, INTR, 1 ); 
DECODE ! POSTAMELE ( NULL ) ; 
RETURN; 

END  "DECI"; 


(Fi«  5.3) 
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PPOCKDURE  INTP; 

BEGIN  "INTP" 

PR0CESS!NAME<-"1NTR"; 

P'AR<-IPA; 

DR<-IP; 

WRITE!MEM(M,'T",l6,40q‘j,  MAR,  4095,0,  DR); 

RETURN; 

END  "INTR"; 

PROCEDURE  FETCH; 

BEGIN  "FETCH" 

PROCESS ! NAME<- "FETCH " ; 

MAR<-PC; 

DR<-READ!M£M(M, "M" , 1 b , 4095 , MA R , 409S , 0 ) ; 

PC<-INCR(<PC>) ; 

RETURN; 

END  "FETCH"; 

PROCEDURE  EXEC; 

BEGIN  "EXEC" 

P P OC  ESS ! N A M E < - " E X EC " ; 

IH<-DR; 

EXTRACTORd  ,1R,4,15); 

MAR<-TMP[ 1 J; 

DR<-PEADIMEM(M,"M", 16,4095, MAR, 4095,0); 

DRK-DR; 

A<-DR; 

EXTRACTORd  ,1R,0,15); 

MAR<-TMPl 1 ]; 

DR<-READ!MRM(M,"M",16,4095,MAR,4095,0); 
DR<-SUBTRACT(<A>,<DR>) ; 

EXTRACTORd ,1R,4,1S); 

MAP<-TMP[ 1 ]; 

DR2<-DR, 

WRITE!MEM(M,"M" , 1 6 , 4095 ,MAR , 4095 , 0 , DR ) ; 

DEC; 

0UT{CHANNELIWRT,CRLF4"  CHKPT  FOR  STATMENT  12  IN  PROCESS 
EXEC"); 

CHKPTSI "DR", DR, 0,0, 4095,-1 ,0); 

CHKPTS("PC",PC,0,0,15,-1 ,0); 

RETURN; 

END  "EXEC"; 

PROCEDURE  DEC; 

BEGIN  "DEC" 

PROCESS ( NA ME DEC"; 

DECODE ! PREAMBLE ( DR , 0 , 4095 ) ; 

DEC0DEIST(0,BR,0); 

I DECODE !POSTAMBLE( NULL); 

RETURN; 


(Fis;  5.3) 


PPOCfeDURE  PR; 

FEGIN  "PR" 

PROCESS !NAME<-"PR"; 

DR<-PC; 

EXTRACTORd  .IRtfeJ*^); 

PC<-TMP[ 1 ]; 

MAR<-PC; 

DR<-READ!yEM(M,"M” , 1 6 , U09P , MAR , R09P , 0 ) ; 
RETURN; 

END  "PR"; 

! INITIALIZATION  Or  VARIABLES; 

RUN<-  ON; 

PC<-  0; 

MAX  I TIMES! THRU! LOOP<-30; 
CHANNEL!WRT<-OPENFILE("FILE" ,"W"); 

SIM; 

CLOSE ( CHANNEL !WRT); 

END  'MAIN"; 


Fif'  E . 3 

The  simulator  for  SIM  based  on  the  Piven 
data  structure  and  control  structure 


CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=4095 

PC=1 

CHKPT 

FOR 

STATMEMT 

12 

IN 

PROCESS 

FXEC 

DR=? 

PC  = ? 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=103 
PC  = 3 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=4094 
PC  = 4 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR  = 3 
PC=5 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DS=104 

PC=0 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DRr4093 

PC=1 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=5 

PC=2 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=103 
PC  = 3 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=4091 
PC  = 4 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=8 

PC=5 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=104 

PCrO 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=4088 

PC=1 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=13 

PC=2 

CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXFC 

DR=103 
PC  = 3 
CHKPT 

FOR 

STATMENT 

12 

IN 

PROCESS 

EXEC 

DR=40B3 

PC=M 


(Fi*  5.4) 
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CHKPT  FOR 
DR=21 
PC  = 5 

STATMFNF 

12 

IN 

PROCESS 

FXEC 

Cr^KPT  FOP 
DR=104 
PC=0 

STATMEK'T 

12 

IN 

PROCESS 

PXFC 

CHKPT  FOR 
DR=4075 
PC=1 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

1 

CHKPT  FOR 
DR  = 34 
PC=? 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

r 

1 

CHKPT  FOR 
DR=103 
PC  = 3 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

CHKPT  FOR 
DR=4062 
PC=4 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

CHKPT  FOR 
DR=55 
PC=5 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

CHKPT  FOR 
DP=104 
PC=0 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

CHKPT  FOR 
DR=4041 
PC=1 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

CHKPT  FOR 
DR=»9 
PC=2 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

CHKPT  FOP 
DR=103 
PC  = 3 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

CHKPT  FOP 
DR=4007 
PC=4 

STATMFNT 

12 

IN 

PROCESS 

EXEC 

CHKPT  FOR 
DR=144 
PC=b 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

r* 

CHKPT  FOR 
DR=104 
PC=0 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

CHKPT  FOR 
DHr3952 
PC=1 

STATMFNT 

12 

IN 

PROCESS 

EXFC 

r 

I 

I 

\ 


Fi<:  5.'« 

Output  from  the  simulator  eenerated  by  the  eheoknoint 
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Chanter  6 
COMCLUSION 

In  this  conoludina  chapter,  we  will  discuss  the  methods  used  to 
build  the  translator,  and  we  will  look  at  some  areas  where  the 
translator  can  be  improved  or  expanded. 

The  translator  has  two  major  components;  the  data  base 
component  and  syntax/code  veneration  component.  Each  of  these 
components  is  encapsulated  in  its  own  procedure,  thus  preventing 
interaction  except  through  external  variables.  All  of  the  routines 
exchange  information  throuvh  procedure  parameters  or  external 
variables.  ►Modularization  is  one  of  the  key  features  of  the 
translator.  This  modularity  allows  us  to  chans’s  routines  in  one 
module  without  affecting  other  routines,  unlike  the  case  of  closely 
Intertwined  routines.  Because  of  this  feature,  the  translator  can 
be  expanded,  changed,  repaired,  and  maintained  easily.  This  is  very 
important  since  any  system  that  is  frecuently  used  will  be 
undergoing  constant  change  and  maintenance  as  new  bugs  are  found  and 
repaired . 

The  translator  Itself  makes  heavy  use  of  macros  internally  as 
well  as  for  code  generation  purposes.  Hacros  were  used  to 
parameterize  the  translator  so  changes  in  constants  would  require 
changes  only  in  the  macros.  This  reduced  the  chances  of  error.  We 
also  used  macros  to  replace  sections  of  code  that  were  frequently 
used,  to  implement  sections  of  code  that  involved  shared  variables, 
and  to  replace  similar  lines  of  code  throughout  the  translator. 
This  improved  the  readability  and  understandabllitv  of  the  program. 


Py  theoe  methodd,  the  traridlator  Can  be  eadily  maintained  and 
improved  in  the  future. 

Aa  we  built  this  traridlator,  mariy  featured  were  encountered 
that  we  felt  would  be  neceadarv  iti  the  dydtem  if  it  were  to  be  uded. 
Manv  of  the  featured  would  be  difficult  to  implement  and  could 
coridume  a great  deal  of  time,  while  otherd  are  replacementd  of 
Current  routined  which,  iri  hiriddight,  could  have  been  improved  ori , 
arid  dome  weren't  needed  to  tret  a badic  traridlator  going. 

Two  of  the  eadier  changed  poddible  concern  the  data  bade  and 
detting  of  traridlator  coridtantd  externally.  The  routined  dealing 
with  the  data  bade  dhould  be  replaced  or  improved.  The  credent 
routined  aren't  very  flexible  rior  are  they  very  tolerant  of  input 
error.  One  of  the  problemd  id  the  proliferation  of  keywordd  iri  the 
declaration  dtatementd  ("the  more  keywordd  the  greater  the  chance  of 
error").  Ari  example  id  the  keywordd  prefixed  with  "dubfld";  thid 
prefix  Can  be  eliminated  arid  the  dyntax  can  be  allowed  indtead  to 
declare  the  item  to  be  a dubfield. 

At  predent,  if  certairi  boundd  coridtantd  are  to  be 
changed (SYMBOL! TABLE  dize,  maximum  number  of  badic  dtatementd  in  a 
block),  the  valued  addigned  to  macro  named  mudt  be  changed  in  the 
traridlator.  Thid  id  clumay  and  inefficient.  Routined  could  be 
written  to  allow  the  Uder  to  det  theae  coridtantd  from  the  coridOle. 
There  are  two  approached:  either  auery  the  uaer  from  the  traridlator 
or  read  the  coridtantd  off  a command  line.  Thid  latter  aoproach  id 
uaed  by  the  SAIL  compiler  to  aet  awitchea  and  acquire  conatarita. 
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Other  aredd  are  more  difficult  to  impleT.ent  and  much  more 
thought  will  be  Involved  in  dedi^triiru?  thi^m.  One  area  is  very 
important,  arid  the  other  two  areas  would  be  useful  arid  necessary  if 
the  system  is  to  be  freouently  used. 

The  most  important  area  is  that  of  determinism.  Two  possible 
alternative  solutions  to  the  problem  have  been  suggested  and  some 
"hooks"  have  been  left  iri  the  trarislator  ori  which  to  haner  one  of  the 
possible  solutions  (the  "set"  solution).  This  problem  should 
receive  priority,  since  a larue  sCale  system  Cannot  be  checked  for 
determinism  by  "eyebdl liru?"  the  desiirn.  This  was  the  method  used  to 
check  the  determinism  of  SIM  iri  Chapter  5. 

At  some  time  someone  will  want  to  test  his  simulator  under  the 
influence  of  interrupts.  This  will  involve  desivnina:  routines  to 
f?enerate  interrupts( i .e.  random  number  generators),  and  some  means 
of  defining  the  desired  interrupt  structure,  and  translating  it  for 
Use  by  the  simulator.  Thus,  a designer  could  specify,  perhaps  in 
the  data  base,  the  interrupt  system  he  wants  (such  as  the  PDP/8 's 
interrupt  system  or  a more  complex  PDP/11  type  interrupt  structure), 
as  well  as  how  the  interrupts  will  appear. 

At  present  if  the  user  has  designed  arid  created  a simulator  for 
machine  "X"  and  wishes  to  add,  delete,  or  change  the  CHECKPOINTS,  he 
must  change  the  translator's  input  and  retranslate  the  entire 
design.  The  simulator  would  be  the  same  with  CHECKPOINTS  in 
different  locations.  It  would  be  more  convenient  if  the  user  could 
specify  CHECKPOINTS  from  the  terminal  before  the  simulator  was  run 
or  during  simulation  like  a debug  oackacre.  Routines  for  doina  this 
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will  be  quite  larc^e  dlnce  IDILIST  cirjd  ‘^YMBOLITABLF  must  be  kept 
along  with  tables  containing  the  location  of  each  basic  statement, 
arid  the  location  of  all  the  current  CHECKPOINTS. 

These  routines  cover  the  more  important  areas  for  growth  in  the 
translator,  atid  the  user  is  sure  to  have  mariy  more  ideas.  The 
preserit  version  of  the  translator  is  basic.  It  Can  handle  small 
desigris  quite  well,  arid  with  some  of  the  additional  routines 
mentioned,  it  will  be  a very  powerful  tool  for  designing  large 
digital  systems. 
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